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BACKGROUND 


Spacecraft design is generally an exercise in design trade-offs: fuel vs. weight, 
power vs. solar cell area, radiation exposure vs. shield weight, etc. Proper analysis of 
these trades is critical in the development of lightweight, efficient, "lean” satellites. The 
modification of the launch plans for the Magnetosphere Imager (MI) to a Taurus launcher 
from the much more powerful Delta has forced a reduction in spacecraft weight availability 
into the mission orbit from 1300 kg to less than 500 kg. With weight now a driving factor 
it is imperative that the satellite design be extremely efficient and lean. The accuracy of 
engineering trades now takes on an added importance. 

In some cases the balance between design utility and design "cost" are clear. For 
example, given the choice for a satellite stabilization system between an active gas jet 
system or a passive mass-spring-damper system, the passive system is clearly the choice in 
terms of cost and reliability if it can provide the necessary performance. Less clear are the 
trades involved in the avionics requirements for a given satellite, particularly when the 
avionics in question interface with the payload instruments. Optimal requirements for 
instrument avionics are difficult to define because they generally involve interactions 
between electrical systems (computers, instruments, power supplies, guidance and control 
electronics, etc.), mechanical systems (instruments, guidance and control hardware, mass 
balance systems, etc.), and information (software, telemetry data, instrument data, 
instrument controller commands). 

An understanding of spacecraft subsystem interactions is critical in the development 
of a good spacecraft design, yet it is a challenge to define these interactions while the 
design is immature. This is currently an issue in the development of the preliminary design 
of the Magnetosphere Imager (MI). The interaction and interfaces between this spacecraft 
and the instruments it carries are currently unclear since the mission instruments are still 
under development. It is imperative, however, to define these interfaces so that avionics 
requirements ideally suited to the mission's needs can be determined. 


PROJECTED INSTRUMENT PAYLOAD 

The proposed MI payload consists of three instruments: (1) the Far Ultraviolet 
Imager (FUV), (2) the Plasmasphere Imager, and (3) the Hot Plasma Imager. Exact 
instrument interfaces are impossible to define at this point of the design process, but some 
general ideas of payload requirements can be gleaned from examining the heritage of the 
payload instruments. 

Wilson (1993) compiled an extensive report on the development history of the MI 
instruments. This report was used in addition to conversations with members of the 
Magnetosphere Imager Science Definition Team (SDT) to gain a better understanding of the 
functional requirements of the payload instruments. The results of this effort are embodied 
in the bullets in the following sections. 

Far Ultraviolet Imapp.r 

♦ Essentially a monochromatic telescope (photon counter) 

♦ Requires a filter wheel and associated motor to move the wheel to look at 

different wavelengths 

♦ Image may be swept across a CCD as the spacecraft rotates, or the instrument 

may use a periscope to stare at one point in the sky 
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♦ May be a problem if the instrument sweeps across a bright object before a darker 
object of interest (blooming) 

• Goal is to produce 1 image per minute 


Commands that may be uploaded include changes in image integration time, 
compression schemes, ON/OFF cycling, instrument status checks, uploading code 
to instruments, performing passive telemetry on instrument, filter wheel movement, 
periscope rate of movement, etc. 


• SDT specified FOV 40°x360° 


• SDT dimensions 

• SDT masses 

• SDT power 

• SDT data rates 

• SDT pointing accuracy 

Elasmasphere Imager 

• Essentially a photon counter 


.70x.80x.30 m 
30 kg 
25 W 
15 kbs 
0.025 deg 


• SDT specified a 135°xl80° FOV but it is likely that the scientists will want data 
from the full spin (135°x360°) 

• The plasmasphere imager cuts a 135° degree swath through the sky as the craft 
rotates. A CCD element will be used to capture the images, either a 1-D array that 
will sweep across a very small field of view, or a wider 2-D array which will allow 
more image integration time as the image sweeps across it. 

• Goal is to produce 1 image per minute 

• Should be able to achieve high data compression ratios with the image files 

• No moving parts 

• Commands that may be uploaded include changes in image integration time, 
compression schemes, ON/OFF cycling, instrument status checks, uploading code 
to instruments, performing passive telemetry on instrument. 


• SDT specified FOV 

135°xl80° 


♦ SDT dimensions 

imager 

electronics 

.48x.16x.20 m 
.23x.18x.20 m 

♦ SDT masses 

imager 

electronics 

7.2 

11.8kg 

• SDT power 

imager 

electronics 

4.5 

16.5 W 
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• SDT data rates 

• SDT pointing accuracy 


7 kbs 


0.5 deg 

li QL P lasma Imager - High and Low Energ y 

* Essentially an event counter, used to look at various q/m ratio particles 

• Instrument will require specification of spin rate from the spacecraft (or ground 

operator) ' " 

• Unusual in that it requires a controllable high voltage power supply 

♦ Goal is to produce 1 image per minute 

* No moving parts 

• Commands that may be uploaded include changes in image integration time, 
compression schemes, ON/OFF cycling, instrument status checks, uploading code 
to instruments, performing passive telemetry on instrument, change in high voltage 
level, temperature data, etc. 


• SDT specified FOV - 4n str 


♦ SDT dimensions 

High Energy 

.51x.35x.51 


Low Energy 

.30x.30x.25 


electronics 

.30x.30x.30 

• SDT masses 

High Energy 

14 kg 


Low Energy 

7 kg 


electronics 

8 kg 

• SDT power 

High Energy 

4 W 


Low Energy 

7 W 


electronics 

12 W 

• SDT data rates 

High Energy 

12 kbs 


Low Energy 

6 kbs 

• SDT pointing accuracy 

5 deg 



THE MI INSTRUMENT-AVTONICS INTERFACE 

The challenge in defining the instrument interface to the MI avionics system is 
centered around the fact that the satellite instruments are still undefined at this point There 
are ways to address this problem, however. What we can do is define two interfaces, 
basically a worst-case and a best-case. These two options are chosen with knowledge of 
only the most basic facts about the instruments such as weight, power, field of view, and 
instrument heritage. With such limited knowledge it is difficult to explicitly design the 
interface, or controller, so the goal is to define with these two designs the spectrum of 
possibilities in which the final instrument control system will fall. We can do this with 
confidence because the requirements and specifications in the previous section do not 
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specify any instrument characteristics that are unusual enough to drastically impact the 
controller design. 

. Option 1 -Distributed Instalment Control. The two instrument control schemes 
conceived for MI are illustrated in Figure 1. The first scheme to be discussed is the 
distributed control scheme. This design is basically the "high performance" option. The 
operation of each science instrument is independent in this design, with each having its 
own computer/controller that acts as the interface between it and the main onboard 
computer. The advantages of this control strategy are numerous. Distributing control to 
each science instrument maximizes the probability of getting at least some data from the 
spacecraft. It also simplifies and compartmentalizes software, saving programming time. 
In this same vein it allows the science instrument developers, who may be geographically 
distributed, development independence. 



Other 

Systems 


Sensor 

Arrays 


FUV Control 
I Computer 

PI Control 
Computer 

HPI-HEH Control 
Computer 


HPI-LEH Control 
Computer 



Figure 1. Sketch of the MI instrument controller options. 

On the other side of the coin, distributed control has design costs that may preclude 
its use. Since each instrument has a dedicated and independent computer that is not 
available for any other tasks, the spacecraft computer may need a backup in case it fails. 
This means that there may be five or six computers that must be qualified for the mission. 
Each computer adds mass, but the overriding consideration may be the cost to space qualify 
all this electronic hardware. Significant savings might be achieved by combining the 
controllers of two or more of the instruments. 
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, Op . tiQn 2-Cgntr alized Inst rument Controller. The logical extension of combining 
two instrument controllers into one is to combine all the instrument controllers into one. 
This master controller is represented in Figure 1 by the dotted box that surrounds the four 
distributed control computers. This strategy results in a number of advantages, including a 
lower mass system, a lower power system, and the need to qualify fewer components. If 
the system is properly designed the master control computer and the spacecraft computer 
could be used as backups for each other, eliminating the need for a backup spacecraft 
computer. This was the control strategy used in the recent low-cost Clementine project at 
the Naval Research Laboratory. 

Obviously there are disadvantages to this method as well. The two most important 
appear to be an increased complexity in the software and the necessity for significant 
coordination among the science instrument designers/builders. 


CONCLUSIONS 

A range of control possibilities are defined by the two control options presented 
herein. It is likely that both will prove to be impractical in some respect: option 1 may 
prove to be too expensive and option 2 may not provide the necessary performance. 
Currently in the overall MI design option 1 is baselined, but there is a risk involved here. 
Option 1 certainly represents a "worst case" option in terms of cost, weight, and power. 
For planning purposes this is a good, conservative, model. The risk comes when talks 
begin with the science instrument builders. If they perceive that the distributed control 
scheme is the baseline scheme, they will be very reluctant to give up any of their control 
computers to save cost and weight If possible, the baseline control system that is 
presented to the instrumenters should be as close as possible to option 2. This will start the 
process at the low cost option and the design process can then proceed in a rational fashion. 
The instrumenters and spacecraft design team can add controllers when performance makes 
it necessary, instead of giving all instruments a control computer, potentially adding 
unneeded weight, capacity, and cost. 
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